Transactional behavior for update activity within a single repository is well understood and has been used by database developers for many years. The transaction technology ensures that multiple actions in order to update a data set in a repository are treated as a single activity and that all updates are either applied or withheld as a single unit of work. The concomitant isolation of the data during this activity ensures that other transactions occurring at the same moment do not see partially updated or pre-updated data. This is known in the art as a single-phase commit.
The concept of single-phase commit has been extended to allow multiple repositories to be updated in a synchronized fashion through the use of two-phase transaction management. The two-phase transaction adds a prepare phase to the standard transaction management; during this phase, the status of the transaction is in doubt. If a failure occurs at this point, a mechanism is available to recover the responses from each repository, and then roll the transaction forwards or backwards depending on those responses.
A problem occurs when trying to perform a two-phase transaction across a number of participants within a transaction. It is important to a transaction manager, in order to be able to manage the participant's actions within the transaction, to know how many participants are participating in the transaction. In a web services environment or within a transaction created and processed as a result of messages being propagated across a multiple domain architecture, determining how many participants are participating in a transaction has proven a very difficult task.
Typically, because a transaction manager does not know how many participants are participating in a transaction, the transaction manager waits for a predetermined amount of time before committing or aborting the transaction. The transaction manager assumes that all participants who are participating within the transaction will register with the transaction manager within the period of time that the transaction manager is required to wait. This, therefore, has a number of disadvantages. Firstly, the transaction manager may commit or abort a transaction unnecessarily, for example, committing the transaction without realizing that a participant has not registered. Secondly, the transaction manager may, for example, be requested to wait for a period of time (e.g., two minutes) before it commits or aborts the transaction. In this time all of the participants may have registered with the transaction manager within the first thirty seconds of the transaction manager's wait period. Thus, the transaction manager has to wait for another one and a half minutes before it can commit or abort the transaction.
Clearly, this imposes a delay in all transactions and is extremely prone to errors due to late or non-registration of participants.